C4 — 网页休闲小游戏批量产线 · 场景指引

文档编号：LTS-C4-GUIDE  |  版本：v1.0  |  更新日期：2026-09-28  |  战役：长周期业务场景测试

一、场景概述

C4 场景是六张核心故事卡中以「三权分立验收」为核心压测对象的唯一场景。所谓三权分立验收，是指在 AI 原生引擎的自动运营流程中，将「执行」「验收」「批准」三项权力彻底分离到不同的角色与 Agent 实例上，使得任何一项交付物都必须经过至少两个独立主体的评判与确认才能进入生产环境。这一设计的根本目的是解决大语言模型驱动的代码生成中一个极为普遍且隐蔽的问题——「自审自批」，即执行编码任务的 AI Agent 在完成代码编写后，自行判断任务已完成并标记为通过，而实际上代码可能存在功能缺陷、逻辑遗漏或不符合验收标准的情况。

在网页休闲小游戏这一具体业务形态下，「自审自批」的危害尤为突出。一个 H5 小游戏从代码层面看可能完全「跑通了」——编译无报错、单元测试通过、甚至 AI 自己执行了一遍通关流程——但真实玩家打开后可能遇到首屏黑屏、第三关卡关无提示、触屏操作不灵敏、包体过大导致加载超时等问题。这些问题只有站在「玩家视角」才能发现，而执行编码的 AI Agent 天然缺乏这种视角。因此，C4 场景要求验收 Agent 必须是一个独立的角色配置，拥有独立的提示词模板、独立的 done_when 验收清单、独立的浏览器实测能力（Playwright 自动试玩 + 断言），其 executor_id 与 reviewer_id 在数据库层面被硬校验为不等，从机制上杜绝同一个 Agent 既当运动员又当裁判员的可能性。

除了三权分立验收这一核心特色之外，C4 场景还同时压测了 qianshou loop 引擎的长时编码能力与接力机制、auto-ops 轮次调度的时间片分配、双执行引擎在同一项目中的协同（loop 引擎负责编码、Agent 引擎负责选题分析与数值核算）、项目级账本预算的单款成本上限与熔断机制、deploy 发布管线的完整链路（从构建到可访问 URL 到回滚）、以及发布后的流量运营与数据驱动排产能力。这些能力的组合使得 C4 成为一个覆盖面极广、验证维度极多的综合性场景。

C4 场景的另一个重要特征是「人工推翻验收结论」的机制设计。即便验收 Agent 已经独立做出了「通过」的判定，系统仍然保留了人工抽检并推翻该结论的通道。当人工试玩发现验收 Agent 遗漏的问题时，可以将验收结论从「通过」改为「驳回」，任务自动退回执行队列进行返工，驳回理由会被写入角色经验库（role_experiences），成为后续验收的参考依据。这一设计确保了在 AI 自主运营的体系中，人类始终保有最终的质量否决权，同时也为验收 Agent 的持续改进提供了反馈信号。

从业务规模的角度看，C4 场景从 T1 阶段的 1 人 + 2 AI 编制、3 款精品 demo 起步，逐步扩展到 T3 阶段的 1 人 + 12 AI 编制、20 款在跑游戏的规模化运营。这一扩展过程本身就是对 auto-ops 调度能力、组织进化（evo）机制、预算管控精度以及事故自愈能力的全面考验。特别是在 T3 阶段，当 20 款游戏同时在线运营时，任何一款游戏的 JS 报错率飙升、广告 SDK 政策违规或成本超支都可能触发系统级的连锁反应，要求平台能够在不影响其他游戏正常运营的前提下进行精准的隔离处置。

二、场景目标与主战场能力

2.1 核心压测目标

C4 场景的核心压测目标可以归纳为三个层次。第一层是验收独立性验证：验证系统能否在无人工逐行审查的前提下，通过独立的验收 Agent 有效拦截「代码跑通但玩家卡关」类缺陷，且整个过程中自审自批记录数恒为零。第二层是长时编码链路的可靠性：验证 loop 引擎能否在单次轮次中完成一个完整 H5 游戏的编码（从 HTML 骨架到 Canvas 渲染到关卡逻辑到埋点），包括接力提示词机制在任务未完成时的续写能力，以及 [Task finished] 标记检测的准确性。第三层是发布后运营的闭环能力：验证游戏上线后的流量数据采集、玩家反馈归因、数据驱动排产、预算跨品类挪移等运营动作能否在 AI 自主模式下高效运转。

2.2 主战场能力矩阵

能力名称	类型	详细说明
三权分立验收	必需 · 核心	开发自测不等于验收。验收 Agent 独立跑 done_when 清单 + 浏览器实测（Playwright 断言：可点击、无 console error、通关路径可达）。验收报告附截图与日志。executor_id 与 reviewer_id 硬校验不等，同角色版本直接拒收。这是本场景的立卡之本。
qianshou loop 长时编码	必需	loop 引擎启动 qianshou 子进程进行真实编码。单轮编码时长基线 457~1389 秒，token 消耗基线 ¥0.78~1.23/轮。接力提示词机制在任务未完成时自动续写。[Task finished] 标记检测是收口关键——D1 首跑发现尾部窗口命中率 0/5，检测窗口错位 + 反问停滞是核心缺陷。
auto-ops 轮次调度	必需	时间片轮转调度多任务并行。轮间 sleep 固定 60 秒。review 重排机制按优先级调整任务队列。free 维护模式确保不误停在建任务。批量排产时按时间片轮转分配编码槽位。
双执行引擎	必需	loop 引擎（qianshou 子进程）负责编码等复杂长时任务；Agent 引擎（进程内 LLM + ToolCall）负责选题分析、数值核算、数据整合等信息密集型任务。优先级：任务级 > 角色级 > 项目默认。D1 首跑已验证同项目 loop 5 轮 + agent 2 轮共存。
账本预算与熔断	必需	单款成本上限 + 项目 AI 运行预算预警线（70%）。三级控制：预警 → 降级 → 熔断 → 恢复。注意：当前作用域为项目级，单款预算包为 P1 建议项尚未实现。超支会暂停整个项目循环，牵连其他款。
deploy 发布管线	必需 · 待补	每款游戏上线出可访问 URL 并可回滚。D1 首跑发现发布面只有宿主半边（5 端点在 router.go），平台/前端零封装，deploy_jobs 全局 0 行（ISSUE-W4-38）。降级方案：复用 mail1 增量目录部署。
知识库	必需	游戏库 / 失败案例 / 规范（性能与包体约束）。沉淀为项目模板供后续游戏复用。第 10 款成本应显著低于第 3 款。
marketing 营销	必需	发布帖 + 合集页 SEO。FIX-002 待 e2e 前发帖留 pending_review 计「已生成待审」，引流转化不进分母。
RACI 人在回路	必需	广告位接入、下架决策走人工批准。三通道决策：绿（AI 自主）/ 黄（人工审核）/ 红（人工批准）。写操作必须人工审核。
evo 扩编	增强	按队列积压扩开发 / 验收岗。FIX-004 待 e2e 前扩编后可能「扩而不用」，需手工绑任务并标注。T2 核心断言：新角色 3 轮内被调度到任务。

2.3 三权分立验收的深度解析

三权分立验收是 C4 场景区别于其他五张故事卡的核心特征，需要从机制设计、运作流程、防弊措施三个维度进行深入理解。

机制设计层面，验收 Agent 在系统中被配置为一个完全独立的角色。它拥有独立的 agent_id、独立的提示词模板（包含 done_when 验收清单的逐项检查逻辑）、独立的技能白名单（只读权限 + Playwright 浏览器实测能力，无编码权限）。当执行 Agent 完成编码任务并提交验收后，auto-ops 调度器会将验收任务分配给验收 Agent，而非原始的执行 Agent。在数据库层面，acceptance_records 表记录了每一条验收记录的 executor_id（执行者）和 reviewer_id（验收者），系统通过硬校验确保这两个字段值不相等。

运作流程层面，验收 Agent 收到验收任务后会执行以下步骤：首先，读取该任务的 done_when 清单（由任务创建时定义，例如「首屏可玩」「无 console error」「包体 < 2MB」「通关路径可达」等）；其次，通过 Playwright 浏览器实测能力打开游戏的部署 URL，逐项执行断言——检查页面是否可加载、核心交互元素是否可点击、是否存在 JavaScript 运行时错误、通关路径是否可达；最后，生成结构化验收报告，包含每项检查的通过/失败状态、截图证据、console 日志摘录，以及最终结论（pass / rework / reject）。

防弊措施层面，除了 executor_id 与 reviewer_id 的硬校验之外，系统还设计了多层防线。第一层是「人工推翻」通道：即便验收 Agent 判定通过，人工仍可在验收列表中对报告进行抽检，若发现遗漏问题可点击「驳回」将结论推翻，任务自动退回执行队列并计入 redo 计数。第二层是验收质量度量：系统持续跟踪一次通过率、驳回准确率、人工推翻率、验收 token 占比等指标，用于动态调整验收强度分级阈值。第三层是飞书通知链路：验收驳回时通过飞书连接器推送通知给相关执行人员，确保返工指令及时传达。

三、预置条件与环境配置

3.1 三端服务基线

端	地址	说明
PostgreSQL 17	localhost:5432	双库：ai_native_engine（平台）/ project_server（实例）。psql 取证只读。
platform 后端	http://localhost:18000	公司/项目/实例/平台真实账本/计费结算/超管后台。WS ws://localhost:18000/ws?token=
project-server	http://localhost:8090	AI 执行引擎。场景轮次/审批/账本/连接器/事件全在此。
前端（vite dev）	http://localhost:5176	三端同机。Playwright 配置 baseURL 5176。

3.2 项目配置参数

项目 lts_c4_game 的运行模式设定为全自动（full_auto），意味着 AI 可以自主推进轮次而无需人工逐轮触发。总预算 ¥9,000 覆盖平台侧计费与外部成本，AI 运行预算 ¥3,000 专门用于 LLM token 消耗，预警线设为 70%（即 AI 已用预算达到 ¥2,100 时触发预警通知）。单轮上限通过 PUT /autoops/config 设定（UI 弹窗无该字段，保存必 500，属已知缺陷 W4-31）。

3.3 验收 Agent 独立角色配置

验收 Agent 的独立角色配置是本场景的关键预置条件。在智能体中心（Agent Center）中，需要创建至少一个专职验收的 AI 角色，其配置要点如下：

• 角色名称：测试专家 / 验收专家（对应岗位模板库中的 QA / Tester 类别）
• 提示词模板：包含 done_when 清单逐项检查逻辑，明确要求「不得因为代码编译通过就判定任务完成，必须实际运行并验证玩家体验」
• 技能白名单：只读权限 + Playwright 浏览器实测（待 P0 建议项落地后启用）；当前阶段以代码审查 + 静态分析为主
• 输出格式：结构化验收报告（JSON），包含每项检查的 pass/fail 状态、截图路径、console 日志
• 独立性保障：该角色的 agent_id 与执行角色的 agent_id 不同，系统在分配验收任务时会自动排除执行者

D1 首跑中已在 UI 智能体中心创建了「测试专家」角色（agent-4c29d259-e3d），但发现该角色在 5 轮后仍零绑定（auto_ops_tasks.role_id 未命中），属于 ISSUE-W4-16B 的复现——deriveRoleKeyForTask 文案命中通道未生效。这一缺陷直接影响验收 Agent 的自动调度，需在后续测试前修复或手工绑定。

3.4 部署目标配置

由于 FIX-007（云开通 UI）未做，C4 场景的部署目标采用降级方案：复用 Linode 实例 mail1（mail1.zyinfo.pro，IP: 172.237.66.31，SG Singapore 2）的增量目录。每款游戏部署到 mail1 上的独立子目录，通过 http://mail1.zyinfo.pro:<port>/games/<game_id>/ 访问。发布管线当前只有宿主半边（5 端点在 router.go:540-549），平台侧和前端零封装（ISSUE-W4-38），因此部署操作需通过 API 直接调用宿主端点完成。

3.5 FIX 修复项影响评估

FIX	内容	状态	对 C4 判定的影响
FIX-001	通知适配器真实化	已实施，待 e2e	验收驳回与上线审批推送按时效记观察项。SLA 与租赁 sweeper 在码（30s/60s ticker），外发适配器亦真实化。人工批准时效由观察项升回实测项。
FIX-002	twitter 连接器	已实施，待 e2e	发布帖留 pending_review 计「已生成待审」，引流转化不进分母。
FIX-003	预算联动	已实施，待重启	单款成本上限靠人工盯 GET .../autoops/billing。三级控制在码且真实驱动（项目级），但作用域是项目级非任务级——超支暂停整个项目，牵连其他款。
FIX-004	扩编调度闭环	已实施，待 e2e	T2 扩的开发/验收岗可能「扩而不用」，需手工绑任务并在报告标注。
FIX-006	计费明细页	未做	单款成本靠 amoeba + psql 取证。注意 amoeba_daily_stats 战役项目读数恒 0，改取 token_billing_records 按 role 聚合。
FIX-007	云开通 UI	未做	复用 mail1 增量目录部署游戏站。

四、T1 生存期操作指引（1–3 款游戏上线）

4.1 UI 路径与冷启动

T1 阶段的冷启动需要按照以下 UI 路径完成全部预置操作。整个过程模拟一个真实用户从零开始在平台上创建游戏工作室并启动 AI 自动运营的完整旅程。

步骤 1：注册登录

访问 http://localhost:5176/login，使用 LTS 测试账号登录（前缀 lts_c4_，密码 test123）。若账号不存在则先注册。登录成功后跳转全局数据面板 /dashboard。

步骤 2：新建公司

点击「新建公司」，公司名称填写 LTS-C4 网页小游戏产线。注意：行业类型枚举为固定 14 项，无游戏/互娱类目且不接受自定义值，只能选择「互联网/IT」。公司创建成功后记录公司 ID（D1 首跑中为公司 974）。

步骤 3：新建项目

进入公司后通过三步向导创建项目。项目名称填写 lts_c4_game（D1 首跑中为 lts_c4_arcade_*）。关键配置：

• 项目类型：枚举仅 5 项，无游戏类，选择 software
• 运行模式：选择全自动（full_auto）
• 总预算：¥9,000
• AI 运行预算：¥3,000（预警线 70%）

步骤 4：自挂实例与配置下发

在项目实例管理中录入 127.0.0.1:8090，触发 grant push。系统会执行 7 步自检流程：instance_host_trusted → instance_registered → grant_push → owner_push → health_check → execution_plane_selfcheck → owner_push(success)。确认 project_config 中 run_mode=full_auto、ai_budget=3000、budget_total=9000 均已同步。

步骤 5：引导流策略确认

进入项目引导流（guided session），填写业务背景：「休闲游戏 / 网页小游戏，H5 轻关卡，可埋广告的轻游戏，目标每周产出 3~5 款」。点击「生成策略」→「确认策略」。此步骤会触发一次真实的 LLM 调用（direct:onboardStrategy），策略确认后 guided_sessions.strategy_confirmed=true。（2026-10-07 注：缺项目作用域确认记录的存量项目，升级后启动会被 hasConfirmedStrategy 闸拦截，重走本步骤即解锁；见 wiki/testing/v3/todo.md V3-07。）

步骤 6：组织起步

在智能体中心创建初始团队：1 个管理者 Agent（经理色）+ 1 个开发全能（fullstack_dev）+ 1 个测试专家（test_expert，兼职验收）。两员工的 parent_agent_id 指向管理者。D1 首跑已验证岗位模板库分类无需手工切换（W4-16A 修复正证）。

步骤 7：创建任务并启动

在 autoops 面板创建 3 条业务任务（1 条 loop 编码 + 2 条 Agent 分析），在提示词模板中显式写入 [Task finished] 要求。点击控制台「启动」按钮，引擎开始自动推进轮次。D1 首跑验证启动通道 code=0，W4-15 冷启动死锁在第二场景不复现。

4.2 选题 → PRD → loop 编码 → 自测 → 提交验收全自动流程

启动后，系统按照以下全自动流程推进每一款游戏的开发：

选题分析阶段由 Agent 引擎执行，分析当前市场热门小游戏类型、竞品数据、广告 eCPM 估算，输出选题报告。此阶段 token 消耗较低（D1 首跑 Agent 轮均 ¥0.005 级别）。

loop 编码阶段由 loop 引擎启动 qianshou 子进程执行真实编码。D1 首跑数据显示 loop 轮均耗时 79 秒（6~132 秒区间），均 token 消耗 ¥0.2505/轮，低于基线带 ¥0.78~1.23/轮——但这不是效率红利，而是因为 task_kind=general 导致 loop 会话落在宿主源码根（W4-40），模型「无处可写」而早退场。

自测 → 提交验收阶段是 C4 场景的关键断点。D1 首跑发现 [Task finished] 标记在会话尾部窗口命中率 0/5（任意位置命中 3/5），检测窗口错位 + 反问停滞导致验收腿从未被触发，acceptance_records 恒为 0。这一问题是 FIX-018 与 W4-17 的核心修复对象。

验收判定由独立的验收 Agent 执行（待 P0 建议项落地后）。验收 Agent 读取 done_when 清单，逐项检查并生成结构化报告。当前阶段由人工替代执行。

人工批准是 RACI 红通道动作。人工在验收列表中对验收报告进行审批，可批准上线或驳回返工。驳回时任务退回执行队列，redo 计数 +1，驳回理由入 role_experiences。

4.3 事件注入

T1 阶段需要注入玩家试玩反馈事件，验证「反馈 → 返工任务」的链路。每款游戏注入 5 条试玩反馈，使用 harness 的 ingest-event.mjs 脚本：

# 试玩反馈事件（卡关）
node ingest-event.mjs --scenario LTS_C4 --type player.feedback \
  --text "卡关第3关，没有提示" \
  --extra '{"game":"g1","issue":"stuck_level_3","severity":"major"}'

# 试玩反馈事件（黑屏）
node ingest-event.mjs --scenario LTS_C4 --type player.feedback \
  --text "打开后黑屏，无法加载" \
  --extra '{"game":"g2","issue":"black_screen","severity":"critical"}'

# 试玩反馈事件（太简单）
node ingest-event.mjs --scenario LTS_C4 --type player.feedback \
  --text "太简单了，5分钟通关" \
  --extra '{"game":"g1","issue":"too_easy","severity":"minor"}'

# 站点 PV 事件
node ingest-event.mjs --scenario LTS_C4 --type site.pv \
  --text "日PV 1200" \
  --extra '{"game":"g1","pv":1200,"date":"2026-09-25"}'

# 广告分成事件
node ingest-event.mjs --scenario LTS_C4 --type payment \
  --amount 18.40 --order-id LTC4-20260925-001

事件注入的统一端点为 POST /api/v1/events（PS，HMAC 三头 X-Project-ID / X-Timestamp / X-Signature）。事件体契约：{source, event_type, title, content, priority, project_id}，其中 content 放业务 JSON 字符串。

4.4 人工动作清单

动作 1：批准 3 次上线

每次上线批准前，人工需核实以下三项：

1. 包体大小：游戏 HTML + JS + 资源总包体 < 2MB（通过 deploy_jobs 或文件系统检查）
2. 无外链敏感域：代码中不存在指向敏感域名的外链（通过静态扫描或人工审查）
3. 埋点合规：广告位接入点、数据采集点符合平台规范

动作 2：人工抽检并推翻验收结论

这是 C4 场景最具特色的人工动作。在 T1 阶段，人工需对至少 2 份验收报告进行抽检，并推翻至少 1 次「通过」结论。具体操作流程：

1. 进入 autoops 验收列表页面（/project/:id/autoops/acceptance）
2. 选择一份验收 Agent 判定为「通过」的报告
3. 人工试玩游戏（打开部署 URL，实际操作 3~5 分钟）
4. 若发现验收 Agent 遗漏的问题（如真人试玩卡关），点击「驳回」按钮
5. 填写驳回理由（如「第 3 关存在不可跳过的死循环 bug」）
6. 确认驳回 → 任务自动退回执行队列，redo 计数 +1
7. 验证驳回理由已写入 role_experiences 表

在验收 Agent 浏览器实测能力（Playwright）与硬校验（executor_id ≠ reviewer_id）落地之前，人工推翻验收结论是验证三权分立验收能力的替代取证手段。即便验收腿当前不可达（acceptance_records = 0），人工试玩并记录问题的动作本身也是有效的质量保障实践。

动作 3：处理验收争议

当执行 Agent 对验收 Agent 的驳回结论有异议时，可发起争议仲裁。争议升级到管理者 Agent 进行仲裁，仲裁结论留痕在 arbitration_cases 与 decision_logs 表中。T1 阶段至少处理 1 次验收争议。

4.5 部署验证

每款游戏部署后，通过 GET .../deploy/:id/url 获取可访问 URL，在浏览器中打开验证游戏可玩。验证要点：

• 页面能否正常加载（无 404、无黑屏）
• 核心交互是否可用（点击、滑动、键盘操作）
• 首屏加载时间是否可接受（< 5 秒）
• 是否存在 JavaScript 运行时错误（打开 DevTools Console 检查）
• 通关路径是否可达（至少能玩到第 3 关）

五、T2 扩张期操作指引（4–10 款游戏，验收流水线化）

5.1 批量排产与时间片轮转

T2 阶段的核心变化是从「逐款开发」转向「批量排产」。auto-ops 调度器按时间片轮转分配编码槽位，多款游戏的开发任务并行推进。操作要点：

• 在 autoops 面板创建 8~15 条业务任务，覆盖选题、编码、关卡设计、数值调优等不同类型
• 观察 /autoops/rounds 每轮被选中任务的分布，确保无任务连续 5 轮未被选中（饿死判定）
• free 维护模式下确认不误停在建任务（连续 2 轮 free 后未完成任务集不变）
• review 轮按数据表现重排优先级（砍低留存、加注高留存品类）

5.2 独立验收全量运转

T2 阶段验收 Agent 应进入全量运转状态。每一款游戏完成后都必须经过验收 Agent 的独立检查。验收清单（done_when）应包含以下标准项：

验收项	检查方式	通过标准
首屏可玩	Playwright 打开 URL + 等待加载	5 秒内出现可交互元素
无 console error	Playwright 监听 page.on('pageerror')	0 条未捕获异常
通关路径可达	Playwright 模拟点击/滑动操作序列	至少到达第 3 关
包体大小	检查部署目录总大小	< 2MB
无外链敏感域	静态扫描 HTML/JS 中的 URL	无黑名单域名
埋点存在	检查广告位占位符与数据埋点	至少 1 个广告位 + 1 个 PV 埋点

低风险游戏可采用抽样验收策略（每 3 款抽 1 款全量检查），但高风险游戏（涉及新引擎、新机制）必须全量验收。

5.3 扩编与调度验证

T2 阶段的核心断言之一是扩编后的新角色真的被调度到任务。操作流程：

1. 观察队列积压情况，当待开发任务 ≥ 8 条时触发扩编建议
2. 通过 POST /org/stage/sense → GET /org/advice 获取扩编建议
3. 在面板中点击「采纳并扩编」，批准 +2 开发 +1 验收岗位
4. 关键断言：psql 验证新角色 3 轮内出现在 auto_ops_rounds 绑定与 token_billing_records.role_id

-- FIX-004 复测：新角色是否被调度
SELECT r.role_id, COUNT(*) AS round_count
FROM auto_ops_rounds r
WHERE r.project_id = ':pid'
  AND r.start_time > ':expansion_time'
GROUP BY r.role_id
ORDER BY round_count DESC;

-- 新角色是否在计费表中出现
SELECT role_id, SUM(cost) AS total_cost
FROM token_billing_records
WHERE project_id = ':pid'
  AND created_at > ':expansion_time'
GROUP BY role_id;

若新角色扩而不用（3 轮后零绑定），则 FIX-004 判定为失败，需手工绑定任务并在报告中标注「人工兜底」。

5.4 验收争议仲裁

T2 阶段需处理至少 1 次验收与执行的争议。典型场景：执行 Agent 认为游戏已满足 done_when 清单，但验收 Agent 判定驳回（如「第 5 关存在概率性崩溃」）。争议升级到管理者 Agent 仲裁，仲裁过程与结论留痕在 arbitration_cases 表。

人工需确认仲裁结论的合理性，并在 decision_traces 中查看完整的决策链路。仲裁结论可能为「维持驳回」「部分通过」或「推翻驳回」，每种结论都应附带清晰的理由。

5.5 小游戏平台审核事件注入

# 审核通过
node ingest-event.mjs --scenario LTS_C4 --type platform.review \
  --text "游戏g3审核通过" \
  --extra '{"game":"g3","result":"approved","platform":"miniclip"}'

# 审核拒绝（附理由）
node ingest-event.mjs --scenario LTS_C4 --type platform.review \
  --text "游戏g5审核被拒：存在未处理的外部链接" \
  --extra '{"game":"g5","result":"rejected","reason":"external_links","action_required":"remove_external_urls"}'

审核拒绝应自动触发整改任务创建并升级验收清单（增加「无外链」检查项的权重）。注意：由于 ISSUE-W4-41 的派单断裂，此事件可能无法自动建任务，需手工创建并记为干预。

六、T3 规模化期操作指引（11–30 款游戏，事故自愈）

6.1 事故演练：JS 报错率飙升

T3 阶段的核心演练是注入一次生产事故：某款游戏的 JavaScript 报错率突然飙升。具体操作步骤：

1. 注入事故事件：

# 事故事件：JS 报错率飙升
node ingest-event.mjs --scenario LTS_C4 --type incident.error_rate \
  --text "游戏g7 JS报错率飙升至35%" \
  --extra '{"game":"g7","metric":"js_error_rate","value":0.35,"threshold":0.05,"severity":"critical"}' \
  --priority urgent

2. 预期系统反应：

• 自动冻结该游戏的发布管线（/deploy/:id/freeze）
• 触发回滚到上一个稳定版本（/deploy/:id/rollback）
• 红通道通知：通过飞书连接器推送告警给负责人
• 在 decision_traces 中留下完整的自动处置链路
• 在 risk_registry 中登记风险条目

3. 人工验证：

• 确认冻结生效：该游戏的 deploy 状态变为 frozen，其他游戏不受影响
• 确认回滚成功：deploy_jobs 中出现 rollback 类型记录
• 确认通知到达：飞书测试群收到告警消息（或 notifications 表中有对应记录）
• 确认 decision_traces 完整：从事件接收到冻结到回滚的全链路可追溯
• 确认事故复盘报告已自动生成，包含根因分析与规则更新建议

6.2 下架决策

对于数据持续低迷或存在不可修复缺陷的游戏，需执行下架操作。下架属于 RACI 红通道动作，必须人工批准。

# 查看候选下架游戏（低留存 + 高成本）
SELECT t.task_name, 
       SUM(b.cost) AS total_cost,
       AVG(CASE WHEN m.metric_name='retention_d1' THEN m.value END) AS d1_retention
FROM auto_ops_tasks t
JOIN token_billing_records b ON t.id = b.task_id
LEFT JOIN game_metrics m ON t.id = m.task_id
WHERE t.project_id = ':pid'
GROUP BY t.task_name
HAVING AVG(CASE WHEN m.metric_name='retention_d1' THEN m.value END) < 0.15
ORDER BY total_cost DESC;

人工在面板中批准下架决策后，系统应自动执行：冻结发布 → 从游戏列表中移除 → 更新合集页 → 记录下架原因到 change_logs。

6.3 预算跨品类挪移

T3 阶段需要验证预算在不同品类游戏之间的灵活调配能力。例如，将低留存品类（如纯益智类）的剩余预算挪移到高留存品类（如动作类）：

1. 通过 PUT .../ledger/budget 批准弹性模式
2. 观察 budget_states 表中预算再分配记录
3. 确认 change_logs 中有完整的挪移操作留痕
4. 验证挪移后低留存品类的任务不会因预算耗尽而突然中断（应有平滑过渡）

6.4 事故复盘与规则更新

事故处置完成后，系统应自动生成复盘报告，人工需确认以下内容：

• 根因分析是否准确（是代码缺陷、引擎 bug 还是外部依赖变更）
• 规则更新建议是否合理（如「所有 Canvas 游戏必须添加 try-catch 包裹 requestAnimationFrame」）
• 新规则是否已写入知识库（knowledge_documents）
• 验收清单是否已相应更新（增加对应的检查项）

七、验收判定表

以下判定表覆盖 T1/T2/T3 三个阶段的核心指标，按故事卡原文阈值设定。判定分三档：通过（绿）、观察（黄）、失败（红）。

T1 生存期判定表

指标	通过（绿）	观察（黄）	失败（红）
自主率（轮次口径）	≥45%	35~45%	<35% 或含未批写动作
自主率（交付物口径）	≥30%	15~30%	<15%
上线动作自主率	恒 = 0（红通道，上线必须人工批准）
干预次数	≤15	16~18（且 FIX 兜底占比 >50%）	>18 或审批链断裂
单款研发 token	≤¥120	≤¥150 收敛中	>¥150
验收成本占比	≤15%	15~20%	>20%
自审自批记录数	0（硬性底线）	—	>0 即失败
首屏可玩率	≥80%	60~80%	<60%
验收返工轮次可见	≥1 次返工留痕	通道齐但无对象	通道不存在

T2 扩张期判定表

指标	通过（绿）	观察（黄）	失败（红）
自主率	≥65%	55~65%	<55%
干预次数	≤10/周	11~14/周	>14/周
单款成本	≤¥80	≤¥100	>¥100
一次通过率	≥75%（从 ~50% 提升）	60~75%	<60%
返工平均轮次	≤1.2	1.2~1.8	>1.8
驳回准确率	≥80%	65~80%	<65%
自审自批记录数	0	—	>0
扩编角色被调度	3 轮内进调度	5 轮内进调度（手工兜底）	扩而不用

T3 规模化期判定表

指标	通过（绿）	观察（黄）	失败（红）
自主率	≥75%	65~75%	<65%
人工升级	≤5/周	6~8/周	>8/周
单款成本	≤¥55	≤¥70	>¥70
事故 MTTR	≤1 轮次（≥60s + 轮耗时）	≤2 轮次	>2 轮次
事故止损完整性	1 轮内闭环 + decision_traces 完整	2 轮内闭环	未闭环或牵连其他游戏
组合留存趋势	上行	平稳	下行
成本/收入按款可算	全款可算	≥80% 款可算	<80%

八、取证口径

C4 场景的取证遵循总方案规定的三重口径（页面 + 网络 + psql），所有关键断言必须跨层交叉验证，单层不定论。

8.1 核心取证表

表名	所属库	取证用途	关键字段
acceptance_records	project_server	三权验收核心证据：验收结论、复核人、时间	executor_id, reviewer_id, verdict, human_status, human_handler, score
auto_ops_rounds	project_server	轮次调度证据：引擎类型、成本、时长、返工轮识别	engine_type, cost, elapsed_sec, start_time, status, reason
deploy_jobs	project_server	发布/回滚链路证据	status, deploy_url, rollback_from, created_at
token_billing_records	project_server	token 成本归因：按 role 聚合 = 单款成本	log_ref, cost, role_id, task_id, created_at
auto_ops_tasks	project_server	任务状态与角色绑定	role_id, finished, round_count, status
decision_traces	project_server	决策链路完整追溯	decision_type, content, created_at
arbitration_cases	project_server	验收争议仲裁记录	status, conclusion, created_at
role_experiences	project_server	驳回理由入角色经验库	role_id, experience_type, content
budget_states	project_server	预算状态与预警记录	ai_used, ai_budget, total_used, total_budget
risk_registry	project_server	风险登记册（事故演练）	risk_type, severity, status, mitigation

8.2 关键取证 SQL

-- 1. 自审自批检查（核心底线：结果必须为 0）
SELECT COUNT(*) AS self_review_count
FROM acceptance_records ar
JOIN auto_ops_tasks t ON ar.task_id = t.id
WHERE ar.reviewer_id = t.role_id;

-- 2. 验收独立性校验
SELECT ar.id, ar.executor_id, ar.reviewer_id, ar.verdict, 
       ar.human_status, ar.score, ar.created_at
FROM acceptance_records ar
WHERE ar.project_id = ':pid'
ORDER BY ar.created_at DESC;

-- 3. 单款成本聚合（按 role 维度）
SELECT role_id, 
       COUNT(*) AS billing_rows,
       ROUND(SUM(cost)::numeric, 4) AS total_cost
FROM token_billing_records
WHERE project_id = ':pid'
GROUP BY role_id
ORDER BY total_cost DESC;

-- 4. 轮次-任务矩阵（调度公平性）
SELECT task_id, engine_type, COUNT(*) AS round_count,
       SUM(cost) AS total_cost,
       AVG(elapsed_sec) AS avg_duration
FROM auto_ops_rounds
WHERE project_id = ':pid'
GROUP BY task_id, engine_type
ORDER BY round_count DESC;

-- 5. 发布/回滚链路
SELECT id, status, deploy_url, created_at, updated_at
FROM deploy_jobs
WHERE project_id = ':pid'
ORDER BY created_at DESC;

-- 6. 预算状态快照
SELECT ai_used, ai_budget, total_used, total_budget,
       ROUND((ai_used / NULLIF(ai_budget, 0) * 100)::numeric, 1) AS ai_usage_pct
FROM budget_states
WHERE project_id = ':pid'
ORDER BY updated_at DESC LIMIT 1;

-- 7. 事故决策链路完整性
SELECT id, decision_type, content, created_at
FROM decision_traces
WHERE project_id = ':pid'
  AND created_at > ':incident_time'
ORDER BY created_at;

-- 8. 扩编角色调度验证（FIX-004 复测）
SELECT r.role_id, a.agent_name, COUNT(*) AS rounds_after_expansion
FROM auto_ops_rounds r
LEFT JOIN agents a ON r.role_id = a.agent_id
WHERE r.project_id = ':pid'
  AND r.start_time > ':expansion_time'
GROUP BY r.role_id, a.agent_name
ORDER BY rounds_after_expansion DESC;

8.3 三重取证交叉验证规则

每一条关键断言必须满足以下交叉验证要求：

1. 页面层（L1）：Playwright 截图入 harness/snapshots/，包含面板数字、状态 tag、审批弹窗内容与按钮态
2. 网络层（L2）：请求 URL / 状态码 + 业务字段 code==0 + 响应关键字段（防 200 伪成功）
3. 数据库层（L3）：psql 只读查询确认落盘行存在性与字段字面量

特别注意事项：

• pserN() 在 psql 空返回时给 NaN，易被误读成「0 行」——NaN/空 ≠ 0，任何「0 行」结论必须复跑一次直查确认
• token_billing_records 是 log_ref 不是 log_path（D1 首跑踩坑点）
• 账本表叫 project_ledger（无 _entries 后缀）
• 三类「日志」须分清：qianshou 会话日志（jsonl）、decision_traces（库表）、服务端运行日志（project-server.log）——禁止跨类互为证据

九、附录：环境信息

9.1 端口映射

服务	端口	说明
PostgreSQL 17	5432	双库：ai_native_engine（平台）/ project_server（实例）
platform 后端	18000	公司/项目/实例/账本/超管后台
project-server	8090	AI 执行引擎（单实例单项目）
前端 vite dev	5176	Vue3 前端开发服务器
外网代理	7890	127.0.0.1:7890（新加坡 IP）
mail1（Linode）	多端口	mail1.zyinfo.pro / 172.237.66.31 / SG Singapore 2

9.2 关键表清单（project_server 库）

分类	表名
事件与派单	events / event_assignments / event_classified
auto-ops 调度	auto_ops_tasks / auto_ops_rounds / auto_ops_schedules / auto_ops_progress / auto_ops_meta
验收与审批	acceptance_records / human_task_nodes / approval_requests / compliance_logs
计费与预算	token_billing_records / budget_states / budget_alerts / project_config / project_ledger / amoeba_daily_stats
组织与角色	agents / org_charts / growth_advice / role_versions / change_logs / role_experiences
决策与审计	decision_traces / decision_logs / arbitration_cases / risk_registry / audit_reports / connector_audit_logs
发布与部署	deploy_jobs / deploy_configs
知识库	knowledge_documents / knowledge_chunks
通知	notifications

9.3 关键表清单（ai_native_engine 平台库）

表名	说明
companies / members / projects	公司/成员/项目基础信息
project_budgets	项目预算（total_budget / used_amount / token_limit）
instances / provision_logs	实例管理 / 配置下发日志
platform_balances / platform_transactions	平台真实账本
token_billing_reports	平台侧计费报告（status: settled/duplicated）
instance_project_grants	实例-项目授权（active/revoked）

9.4 Harness 脚本用法速查

脚本	用途	常用命令
lib.mjs	健康探测 + 取 token + 只读 SQL	node lib.mjs（自检） node lib.mjs --with-proxy（含外网）
drive.mjs	auto-ops 驱动（观察/触发 review/分析）	node drive.mjs（观察轮） node drive.mjs --mode review --wait 240（触发 review） node drive.mjs --scenario LTS_C4 --label "T1-D2"
ingest-event.mjs	外部事件注入	node ingest-event.mjs --scenario LTS_C4 --type player.feedback --text "..." node ingest-event.mjs --type payment --amount 18.40 --order-id LTC4-xxx node ingest-event.mjs --replay-pending（续跑重投）
approve.mjs	审批模拟器	node approve.mjs --dry-run（只出判定） node approve.mjs --scope human,acceptance node approve.mjs --selftest（端到端自证）

9.5 断点续跑指令

# 断点续跑（D2 主用法：建任务→启动→等轮次→验收→停止）
cd platform-web
LTS_C4_PROJECT=<pid> npx playwright test --config=e2e/playwright.config.ts \
  e2e/stories/lut-c4-t1_ui.spec.ts --grep "C4-(7|8|9|10)" --retries=0 --reporter=list

# 只做法证复跑（无写操作，W4-17/FIX-018 换装后回归 tailHit）
LTS_C4_PROJECT=<pid> npx playwright test --config=e2e/playwright.config.ts \
  e2e/stories/lut-c4-t1_ui.spec.ts --grep "C4-8 " --retries=0

# 注意：grep 步号后必须带空格（否则 C4-10 被一起捞走）
# 跑 spec 必带 --config（:5176）
# 重启引擎只需 UI「启动」（W4-15 不复现）

9.6 账号体系

别名	账号格式	用途
lts_c4 主账号	lts_c4_<timestamp>_<rand>@test.com	C4 场景测试主账号，密码 test123
platform_admin	admin_test_m13@test.com	平台超管（user_id=21），harness 默认身份
测试收件箱	hayoou_com@126.com	邮件外发真实冒烟的唯一收件地址
飞书	自建应用	审批推送/通知链路验证

文档维护说明：本文档基于 D1 首跑（2026-09-24）的实测数据与判据修正（2026-09-27 主控现算）编写。随着 FIX 修复项的落地与后续测试轮次的推进，部分判定与阈值可能需要更新。请以最新 STATUS.md 与故事卡原文为准。代码层面的详细知识以最新 git log 与代码为准，文档与代码不符时以代码为准。
2026-10-07 同步（V3 API 回归战役，见 wiki/testing/v3/）：本卡流程路径经复核不变；同族语义收紧两处——验收域双签同人禁签拒绝由 500 改 409/3001、预算阈值百分比 >100% 拒绝（=100 放行）；存量项目启动闸注记见步骤 5（V3-07）。